Web application firewall

ABSTRACT

Embodiments described herein provide an application programming interface and framework for a web application firewall single policy model. The framework can layer on top of a firewall platform that provides web application specific widgets that may be toggled and configured to enable or disable certain firewall actions on a per application basis. The framework includes a security stack that defines the order for the widgets. The security stack can provide the ability for a single policy model to be used for the firewall and allows for per application customizations.

FIELD

Embodiments described herein generally relate to the field of firewallsand network security.

INTRODUCTION

Large enterprises use web firewalls to filter inbound and outboundnetwork traffic to monitor for activity including malicious activity.Web firewalls can be implemented using a combination of hardware andsoftware. An example enterprise that uses firewalls is a financialinstitution. The financial institution may operate many web services orapplications that may each have a need for their own specific firewallpolicy. A single firewall policy might not be applicable to all webapplications hosted by a financial institution. For example, one webapplication may need its traffic restricted in a particular manneraccording to a particular set of rules, while another web applicationmay not function at all under the rules from the first application. Theresult is typically a watered-down policy for all that does not offermuch protection, and no customization.

A developer might have to program their own firewall policy rules foreach web application in a programming environment that runs on aparticular vendor's firewall platform. However, this approach is timeconsuming and difficult as it requires a skilled programmer to modifycode every time a change is needed.

SUMMARY

In an aspect, embodiments described herein provide a firewall systemwith a processor executing code to configure widgets for webapplications and a security stack that provides an order of executionfor the widgets and an activation configuration to toggle each widget toenable or disable security actions on a per web application basis. Thewidgets being security widgets and state control widgets, the securitywidgets having code to implement behaviour analysis detection andsignature detection for a request received from an application, thestate control widgets having code to implement decision making fornetwork traffic.

In some embodiments, the state control widgets have an initializationstate control widget that provides a placeholder for security statelogic to be executed as soon as the request is received and prior to anysecurity detection by the security widgets.

In some embodiments, the state control widgets have a post-inbound statecontrol widget that provides a placeholder for security state logic tobe executed after the request has been inspected for possible attackviolation and before it is either sent to the web application orrejected all together.

In some embodiments, the state control widgets have a post-outboundstate control widget provides a placeholder for security state logic tobe executed after the response has been inspected for possible attackviolation and before virtual patching.

In some embodiments, a widget is a code segment that implements WAFevent listeners to provide particular firewall control functionality andinteract with incoming or outgoing network traffic from the webapplications.

In some embodiments, a widget that is disabled for a particular webapplication is bypassed by network traffic for the particular webapplication.

In some embodiments, the widgets includes a zero-tolerance widget suchthat any triggering of the zero-tolerance widget results in the widgetperforming a prescribed action.

In some embodiments, the widgets include a widget such that a prescribedaction is only taken if a certain threshold of activity is surpassedover a given time.

In some embodiments, each widget has settings or switches, the switchesincluding a kill switch to apply or ignore the widget.

In some embodiments, a security widget comprises code to implementsecurity controls to process and inspect network traffic for a webapplication, the security controls for different types of detection in agiven portion of data exchange with a web application.

In some embodiments, the security stack provides the order of executionfor the widgets by assigning an execution priority value to each widgetto define timing data for execution of the respective widget.

In some embodiments, the signature detection comprises custom signaturedetection and attack signature detection.

In some embodiments, the security widgets comprises code to implementvirtual patch protection to remediate application securityvulnerabilities through HTTP response modification.

In some embodiments, the behaviour analysis detection comprises code toimplement behavioral analysis type of detection to blacklist addressesand perform pattern detection.

In some embodiments, the signature detection comprises code to implementcustom signature type of detection to detect references to maliciousdomains and complex multi-staged signatures.

In some embodiments, the signature detection comprises code to implementattack signature type of detection to track and determine frequency ofsignature detection for cumulative tolerance attack sets.

In some embodiments, a widget implements at least one WAF event listenerto enable the widget to interact with inbound and outbound networktraffic, wherein the WAF event listener declares a priority value forthe security stack to determine the order of execution.

In some embodiments, a security widget implements a set of switches toallow granular flow control, the set of switches comprising at least oneof a kill switch, enforcement switch and a block switch, the kill switchproviding the ability to disable a security control at a policy level,the enforcement switch providing the ability to set a control in eitherdetection or protection mode, the block switch providing the ability toforce the control to reset a TCP connection instead of sending back aviolation message through a HTTP response.

In some embodiments, a widget is an attack signature set to enabledifferent types of tolerance for a particular activity relating to a webapplication, the different types of tolerance being zero tolerance andcumulative tolerance.

In some embodiments, the security widgets comprises a set of securitywidgets relating to inbound traffic flow and another set of securitywidgets relating to outbound traffic flow, wherein the set of securitywidgets relating to inbound traffic flow comprise an abusive sessioncontrol, a domain control, and a signature control, wherein the set ofsecurity widgets relating to outbound traffic flow comprise a signaturecontrol and virtual patch protection.

In some embodiments, a security widget has one or more thresholds, thethresholds relating to volume thresholds or time thresholds.

In another aspect, embodiments described herein provide a process forfirewall system. The process involves, at a processor, receiving arequest at a web application to process network traffic; triggering aninitialization state control widget; processing the network trafficusing security widgets having security logic to implement behaviouranalysis detection, custom signature detection for the request, andattack signature detection based on the request for attack signatures;triggering a post-inbound state control widget; processing the networktraffic using the set of security widgets having security logic toimplement custom signature detection for the response, and standardattack signature detection for the response; triggering a post-outboundstate control widget; implementing viral patch protection; andtriggering the finalization state control widget.

In some embodiments, the initialization state control widget provides aplaceholder for security state logic to be executed as soon as therequest is received and prior to any security detection by the securitywidgets.

In some embodiments, the post-inbound state control widget provides aplaceholder for security state logic to be executed after the requesthas been inspected for possible attack violation and before it is eithersent to the web application or rejected all together.

In some embodiments, the post-outbound state control widget provides aplaceholder for security state logic to be executed after the responsehas been inspected for possible attack violation and before virtualpatching.

In accordance with an aspect, there is provided a framework for a webapplication firewall. In accordance with an aspect, there is provided aframework for a web application firewall single policy model. A policymodel can be implemented using computer code to specify and enforcesecurity policies. A web application is a client server computer programin which the client can run in a web browser. A web application can alsorefer to an application on a mobile device, for example, that may nothave a web browser but uses a client server model.

In accordance with another aspect, there is provided a framework tolayer on top of a firewall platform. The firewall framework provides webapplication-specific widgets that may be toggled and configured toenable/disable certain firewall actions on a per-application basis, andthat can be easily updated without requiring any programming from theend user. The framework can involve a security stack. The security stackprovides the ability for a single policy model to be used for thefirewall, while also allowing per-application customizations.

As used in the security stack, a widget is an application of programcode that provides particular firewall control functionality. Widgets ofdifferent types are processed in the security stack. If a widget is notto be used for a particular web application, it can be bypassed for thatapplication's traffic. Only after passing through all of the toggledsecurity widgets will inbound network traffic get past the firewall. Fortraffic leaving the financial institution network, different securitywidgets may also be applied to conduct analysis. The traffic leaving thefinancial institution network passes through all of the toggled widgetsfor outbound processing. If the traffic is cleared through thosewidgets, the outbound traffic may still be modified or “patched” beforebeing sent out, particularly where the web application has a knownvulnerability.

In the event that a web application has received an exemption from anyof the implemented security widgets, or from firewall filtering overall,its traffic may still be processed by the firewall framework. In thatcase, if any security widget is flagged by any traffic for that webapplication, it will be logged and an internal notification may be sent.For example, the internal notification can suggest that the applicationshould have its exemption revoked.

In addition to the overall concept of the security stack, embodimentsdescribed herein relate to individual security widgets. For example,widget functionality may implement different types of tolerance forparticular activity. If zero tolerance, any triggering of the widget canresult in the widget performing a prescribed action.

Embodiments described herein relate to “cumulative tolerance” such thata prescribed action may only be taken if a certain threshold of activityis surpassed over a given time period. This can help to avoid triggeringexcessive false positives while also being able to try to capture typesof network attacks that come in at a slow rate over time.

Each widget may have settings or switches associated with it, such as akill switch to apply or ignore the widget.

Many further features and combinations thereof concerning embodimentsdescribed herein will appear to those skilled in the art following areading of the instant disclosure.

DESCRIPTION OF THE FIGURES

Embodiments will now be described, by way of example only, withreference to the attached figures, wherein in the figures:

FIG. 1 is a diagram of a firewall system according to some embodiments;

FIG. 2 is a diagram of a firewall system according to some embodiments;

FIG. 3 is a diagram of a process for a web application firewallaccording to some embodiments;

FIG. 4 is a diagram of an interface for a web application firewallaccording to some embodiments;

FIG. 5 is a diagram of an overview of the firewall system framework;

FIG. 6 is a diagram of a security stack process according to someembodiments;

FIG. 7 is a diagram of an application programming interface formalicious request handling according to some embodiments;

FIG. 8 is a diagram of an application programming interface forapplication vulnerability patching according to some embodiments;

FIG. 9 is a diagram of an application programming interface forframework support according to some embodiments;

FIG. 10 is a diagram of a security stack process according to someembodiments;

FIG. 11 is a diagram of a security stack process for abusive sessiondetection according to some embodiments;

FIGS. 12A and 12B are diagrams of a security stack process for embeddeddomain detection according to some embodiments;

FIGS. 13A and 13B are diagrams of a security stack process for standardsignature detection according to some embodiments;

FIG. 14 is a diagram of a security stack process for response codedetection according to some embodiments;

FIG. 15 is a diagram of a security stack process for standard signaturedetection according to some embodiments;

FIG. 16 is a diagram of a security stack process for post inboundrequest handling according to some embodiments;

FIG. 17 is a diagram of a security stack process for HTTP headersaccording to some embodiments;

FIGS. 18A and 18B are diagrams of a security stack process for cookiesaccording to some embodiments;

FIG. 19 is a diagram of a security stack process for CORS according tosome embodiments;

FIG. 20 is a diagram of a security stack process for clickjackingaccording to some embodiments;

FIG. 21 is a diagram of a security stack process for cache controlaccording to some embodiments; and

FIG. 22 is a diagram of a computing device for implementing aspects ofthe firewall system according to some embodiments.

DETAILED DESCRIPTION

FIG. 1 shows an example firewall system 100 according to someembodiments. The firewall system 100 provides a framework for a webapplication firewall. The framework can be used to implement a webapplication firewall single policy model. As shown, firewall system 100connects to web application 104 via network 108. Firewall system 100also connects to one or more user devices 102 and one or moreadministrator devices 106. Firewall system 100 can exchange data withinternal systems or external systems 110.

Firewall system 100 provides a framework to layer on top of a firewallplatform. A firewall platform can include configured hardware andsoftware to implement technological barriers to prevent unauthorized orunwanted communications between computer networks or hosts. The firewallsystem 100 provides widgets specific to web applications 104 that may betoggled and configured to enable or disable certain firewall actions ona per-application basis. The firewall system 100 and widgets can beeasily updated without requiring any programming from the end user. Thewidgets can be toggled and configured by user device 102 andadministrator device 106. The firewall system 100 framework comprises asecurity stack to be described further in relation to FIG. 6. Variouswidgets that can be generated and used by the firewall system 100 aredescribed herein, including security widgets and state control widgets.The widgets can be activated and toggled for web applications 104 toprovide a flexible policy framework specific to particular webapplications 104. The security stack provides the ability for a singlepolicy model to be used for the firewall, while also allowingper-application customizations.

As used in the security stack, a widget is an application of programcode that provides particular firewall control functionality for webapplication 104. Widgets of different types are processed in the orderdefined by the security stack. That is, the security stack defines theorder of widgets to process incoming or outbound network traffic. If awidget is not to be used for a particular web application, it can bebypassed for that web application's 104 traffic. Only after passingthrough all of the toggled security widgets will inbound network trafficget past the firewall system 100. The activation of the security widgetcan be defined in the security stack. The security stack can includecode for activation configurations to toggle the security widgets foractivation or de-activation. For traffic leaving the financialinstitution network 108, different security widgets may also be appliedto conduct analysis. If the traffic is cleared through the widgets for aweb application 104 and reaches an outbound control widget (which may bereferred to as a Post Outbound State Control Widget herein), theoutbound traffic may still be modified or patched before being sent outto internal systems or external systems 110, particularly where the webapplication 104 has a known vulnerability. User device 102 may exchangedata with web application 104 and that data can be network traffic thatcan be filtered by firewall system 100. Administrator device 106 canconfigure widgets and the security stack for firewall system 100.

In the event that a web application 104 has received an exemption fromany of the implemented security widgets, or from filtering overall byfirewall system 100, its traffic may still be processed by the firewallsystem 100. In that case, if any security widget is flagged by anytraffic for that web application 104, it will be logged and an internalnotification may be sent perhaps suggesting that the web application 104should have its exemption revoked.

FIG. 2 is a diagram of a firewall system according to some embodiments.Firewall system 100 can include an interface unit 208, a security stackunit 210, an application programming interface (API) 214, a widget unit212, and databases 216 for storing firewall related data. Security stackunit 210 configures and creates security stacks for web applications104. The security stack defines a processing order for widgets. Theprocessing order can define the order for widgets to process traffic.The security stack can also include an attack signature set. Thesecurity stack provides the ability for a single policy model to be usedfor the firewall system 100, while also allowing customizations forspecific web applications 104. The widget unit 212 generates andconfigures widgets for processing by security stack. The widget unit 212enables generation of different types of widgets including securitywidgets and state control widgets. The widgets can be toggled andconfigured to enable and disable certain firewall actions on a perapplication basis. A widget is code segment that provides particularfirewall control functionality periods. Widgets of different types areprocessed in the order defined by a security stack. If it widget a notused for particular web application 104 it is simply bypassed for thatweb application's 104 traffic. Only after passing through all of thetoggled security widgets will inbound network traffic get past thefirewall system 100. Network traffic for a particular web application104 is processed by different security widgets. There can be manydifferent types of security widgets. For example, a widget can definedifferent types of tolerance for particular activities. If the widgetdefines zero-tolerance then any triggering of the widget would result inthe widget performing a prescribed action. For varied tolerance, aprescribed action may only be taken if a certain threshold of activityis surpassed over a given time period. This may help avoid triggeringexcessive false positives while also being able to try to capturedifferent types of network attacks that can come in at a slow rate overtime. Each widget may have settings or switches associated with it suchas a kill switch to apply or ignore the widget. Further details ofwidgets will be described herein. The interface unit 208 can generateand update an interface 202 for display at user device 102 or aninterface 206 for display at administrator device 106 to configuresecurity stacks and widgets.

The firewall system 100 also includes an API 214 for widget development.The API 214 can integrate with widget unit 212 to configure and developwidgets. The API 214 supports the framework and provides an abstractionlayer to the underlying security product. The API 214 allows securitydevelopers to build widgets with ease and consistency. The API 214defines methods delivered through multiple virtual objects. A virtualobject is syntax based naming convention simulating a desired objectbased grouping, normally found in compiled languages.

FIG. 3 is a diagram of a process for a web application firewallaccording to some embodiments. At 302, the firewall system 100 generateswidgets 302. As noted there may be different types of widgets such assecurity widgets and state control widgets. At 304, the firewall system100 defines or creates a security stack for a particular web application104. The security stack defines an order for widgets to process networktraffic. At 306, the firewall system 100 initializes and configureswidgets for a particular web application 104. As noted, the firewallsystem 100 enables customization for particular web applications 104such that a set of widgets can be toggled or activated for processingnetwork traffic related to the particular publication 104. At 308, thefirewall system 100 processes network traffic for the web application104. At 302, the firewall system 100 stores and transmits the resultsfile relating to the network traffic processing. The results file caninclude data regarding potential attacks and other results received fromwidgets. This can generate a log file for the network traffic. At 312,firewall system 100 generates interface 202, 206 to update the securitystack, view log files of the processing results, toggle widgets forparticular web applications 104, and so on. The operations of theprocess for the web application firewall can be executed in differentorders.

FIG. 4 is a diagram of an interface 202, 206 for a web applicationfirewall according to some embodiments. The interface 202, 206 can beused to define a security stack, generate widgets, toggle or configurewidgets for particular web applications 104, and so on. The interface202, 206 can be used to exchange data with web applications 104 asinbound and outbound data for firewall system 100. The interface caninclude different indicia implement as a visual elements that can beactivated to initiate different processes, such as the creation ofwidgets, for example.

FIG. 5 is a diagram of an overview of the firewall system framework. Thefirewall system 100 can control delivery of security controls. Thefirewall system 100 can provide augmented defense capabilities. Thefirewall system 100 can provide adaptability through configuration.

The firewall system 100 provides a new and innovative web applicationfirewall (WAF) policy model that can enable on organization to betterits security posture while ensuring no business disruption. The firewallsystem 100 can promote consistency of security controls across allapplications. The firewall system 100 can minimize support andoperational requirements. The firewall system 100 can de-coupleadministration from engineering.

In some embodiments, the firewall system 100 can provide a flexiblesolution with a focus on our business partner's challenges. The firewallsystem 100 can implement dynamic, effective and valuable defenses toaugment our application security posture. The firewall system 100 canimplement virtual patches to address standard applicationvulnerabilities. The firewall system 100 can implement meaningfulnotifications to provide actionable intelligence to stakeholders.

A WAF policy model based on previous approaches can be difficult toimplement into a large and dynamic organization such as an establishedfinancial institution. A hurdle can be associated with the policystructure, which can confine an organization to only a couple ofapproaches. An example approach can be to develop application basedpolicies or a policy tailored specifically for an application. Thisapproach can lead to costly development and maintenance with strenuousadministration. Another example approach is to develop vulnerabilitybased policies or a policy tailored not to disrupt normal operation ofselected applications. This may provide reduced protection.

In addition to the structure limitation, policy attributes themselvescan contribute to the rigidity of the current model. For example, apolicy can only be deployed in two global enforcement modes: transparentmode and a blocking mode. The enforcement mode applies to all thesecurity controls in the policy. An exception is the attack signaturesthemselves which can be in alarm mode only regardless of the enforcementmode. Signatures that trigger false positives must be abandoned. Somecustomizable policy settings are prone to conflicts between applicationswhere component names are the same, while having different behaviorsand/or security needs, e.g. application cookies.

In addition, the organization can also face cultural challenges whichunfortunately resulted in very little support to implement a WAF inblocking mode. The following provide examples of feedback provided fromdifferent organizations involved in firewall policy development.Infrastructure partners can be opposed to solutions that require complexcustomization per application. Business partners can be opposed to anysecurity controls that could disrupt normal business operation. Threatsshould be addressed.

Embodiments described herein provide a firewall system 100 that includesa framework and an API. The framework can define an ecosystem ofinnovative capabilities and integrated communication channels. The WAFsecurity controls the components and concepts implemented by theframework to support the attributes shown in FIG. 5.

The table provides a high level perspective on the components andconcepts implemented by the framework of firewall system 100:

Element Description Compo- Security Security widgets are small to mediumamounts of nent Widget code enabling the controlled delivery ofexisting, enhanced or net new security capabilities through an existingplatform. Individual security controls are referred as Security WidgetsState State control widgets are small amounts of code Control used fordecision making at various key points of Widget the workflow Thesecontrols provide the ability to analyze state, activated defenses,custom switches and determine how to further proceed with the workflowWork- Security The security stack is primarily defined as a flow Stackcollection of integrated widgets: State Control (Workflow) Widgets andSecurity Widgets Widgets implement WAF event listeners and executionpriority value to define the exact timing by which they will participatein the security stack The WAF event listeners allows a widget tointeract with the incoming and/or outgoing traffic Security widgets caneither operate independently from one another or alter their functionbased on shared information Config- Switches Kill Switch allows for thecontrol to be uration disabled across the board Enforcement Switchallows for the control to be in either detection or protection modeNetwork Block Switch allows for the control to reset the TCP connectionin lieu of sending back a violation message Exception Applicationexception list allows for an List application to be exempted from asecurity control Application Component allows for an applicationcomponent to be exempted from a security control Threshold Volume canrefer to the number of violation instances to measure against TimeWindow can refer to the amount of seconds to factor in for frequencyevaluation or penalty against a given IP Attack Grouping Zero Tolerancecan refer to the grouping of Signa- signatures that are deemed mandatoryby the ture Set organization Cumulative Tolerance can refer to thegrouping of signatures that will be evaluated based on their frequencyof appearance

FIG. 6 is a diagram of a security stack process 600 according to someembodiments. The security stack is a chain process to govern the orderof execution of all state control and security widgets in the securitystack(s).

At 602, an HTTP request can trigger a security stack. At 604, thesecurity stack involves initialization of a state control widget. At606, 608, the security stack implements behavior analysis detection forthe security widgets. At 610, 612, the security stack implements requestcustom signature detection for the security widgets. At 614, 616, thesecurity stack implements standard attack signature detection for attacksignatures associated with the security widgets. At 618, the securitystack triggers the “Post Inbound State Control Widget” when inboundnetwork traffic goes past the firewall. The security stack defines theplacement for each widget based on their type and function performed. At620, the security stack implements a response to the request. At 622,624, the security stack implements response custom signature detectionfor the security widgets. At 626, 628, the security stack implementsresponse standard attack signature detection for attack signaturesassociated with the security widgets. At 630, the security stackimplements a post-outbound state control widget when outbound trafficgoes past the firewall. At 632, 634, the security stack implementsvirtual patch protection for the security widgets. At 636, the securitystack implements finalization using a state control widget. Thisprovides an example process 300 for the security stack. The securitystack can define an order for different security widgets (1 . . . N)applicable to a particular web application 104. The security stack cantoggle different security widgets (1 . . . N) for a particular webapplication 104.

The security stack can provide an oversight on the security widgets andtheir respective functions. The framework defines state control widgets.The state control widgets allow for security state logic to be executedat key points in time in the security stack. The table provides anexample function breakdown for each widget:

Type Function Description State Initialization Provides a placeholderfor security Control State Handling state logic to be executed as soonWidget as the HTTP Request is received and prior to any securitydetection. The logic can function to: initialize sessions; resetcounters; and centralize global values. Post Inbound Provides aplaceholder for security State Handling state logic to be executed afterthe HTTP Request has been inspected for possible attack violation andbefore it is either sent to application or rejected all together. Thelogic can function to: control whether the HTTP Request should beblocked instead of being sent to the application; and modify HTTPHeaders before being sent to the application. Post Outbound Provides aplaceholder for security State Handling state logic to be executed afterthe HTTP Response has been inspected for possible attack violation andbefore Virtual Patching. Finalization Provides a placeholder forsecurity Handling state logic to be executed at the very end of theworkflow

The security stack can provide a framework that can implement both an“Initialization” and “Post Inbound” state control widget.

To provide comprehensive layer 7 security coverage, the framework candefine distinct placeholders for security widgets, for example. Eachplaceholder can represent a specific type of detection in a givenportion of the HTTP Request/Response data exchange. The below tableprovides an example function breakdown for each them:

Function Description Security Behavioral Provides a placeholder forlogic that handles Widget Analysis behavioral analysis type of detectionsuch as Detection for example: to blacklist IP; and to perform patterndetection. Custom Provides a placeholder for logic that handlesSignature custom signature type detection, for example Detection to:detect references to malicious domain; detect complex multi-stagedsignatures. A separate placeholder is defined for the HTTP Request andResponse Standard Provides a placeholder for security logic that Attackcontrols how attack signature sets behave, Signature for example to:track and analyze the Detection frequency of signature detection forcumulative tolerance attack sets. A separate placeholder is defined forthe HTTP Request and Response Virtual Provides a placeholder forsecurity logic that Patch needs to be executed to remediate Protectionapplication security vulnerabilities through HTTP response modification

Although each function type is optional, the framework can require thata minimum of one function type be implemented. In some exampleembodiments, the firewall system 100 can indicate that all widgetsimplement 1-N WAF event listeners and execution priority value to definethe exact timing by which they will participate in the security stack.

The firewall system 100 involves different types of widgets thatimplement different functions. An example widget type is a securitywidget. Another example widget type is a state control widget. Anotherexample widget type is an attack signature set.

Each security widget can implement at least one WAF event listener. WAFevent listeners allow a security widget to interact with the inboundand/or outbound traffic. WAF event listeners can be declared with apriority value to determine their order of execution. The priority valuecan align with the widget placement in the security stack as well as thedirection of the HTTP traffic intended to be analyzed and/or modified.The direction of the traffic may be a response or a request.

Each security widget can implement a suite of switches to allow granularflow control. These switches can be controlled by configuration listsexternal to the policy. The table below provides the function anddescription of each switch.

Function Description Switches Kill Provides the ability to disable asecurity control at the policy level. This functionality can be usedfor: urgently shutdown a problematic widget; de-coupling deployment andoperation of new security controls Enforce- Provides the ability to seta control in either ment detection or protection mode. Thisfunctionality can be used for: deploying new security controlprogressively and determining unforeseen application impact; gatheringmetrics regarding a particular threat. Network Provides the ability toforce the control to reset Block the TCP connection instead of sendingback a violation message through the HTTP response. This functionalityis primarily used for: disrupting automated vulnerability scanners andprocesses attacking applications.

Each security widget can implement an exception switch. The switch canbe controlled by configuration lists associated to the widget andexternal to the policy. The exception granularity varies per securitywidget ranging from the application as a whole to an applicationcomponent e.g. cookie. The configuration list can facilitate theintegration and management via a separate solution e.g. IT Riskexception process.

Each security widget can implement event logging to provide a cleardepiction of an attack. The event logging can be referred to as aresults file. A security widget can generate a results file. Both attackdetection and exception conditions can be logged in the results file.The table provides example conditions that can trigger event logging.

Condition Standard Behavioral Custom Attack Vulnerable AnalysisSignature Signature Response Exception Undesired Attack type Attack typeApplication Exempted behavior Offending Associated vulnerabilityapplication Offending IP Input signature set requiring a TriggeredOffending patch Violation Input

Each security widget can contribute to the aggregation of attack volumemonitored by other security widgets.

Another example widget type is a state control widget. Each statecontrol widget can implement at least one WAF event listener. WAF eventlisteners can allow a widget to interact with the inbound and/oroutbound traffic. WAF event listeners can be declared with a priorityvalue to determine their order of execution. The priority value alignswith the widget placement in the security stack as well as the directionof the HTTP traffic intended to be analyzed and/or modified. In someembodiments, session based variables are declared with a “vg” prefix.The prefix can be used as a clear indicator that the variable is globalin scope and will exist across all other state control and securitywidgets in the security stack.

Another example widget type is an attack signature set. The attacksignature sets enable different types of tolerance for a particularactivity. A zero-tolerance set can indicate that any triggering of thewidget results in the widget performing the prescribed action. Acumulative tolerance can indicate that a prescribed action may only betaken if a certain threshold of activity is surpassed over a given timeperiod. This may help avoid triggering excessive false positives willalso being able to try to capture different types of network attacksthat come in at a slow rate over time, for example. Accordingly, theimplemented attack signatures can be inserted into one of the followingtwo example groups: (1) Zero Tolerance; (2) Cumulative Tolerance.

Zero tolerance represents signatures that are mandatory and will beblocked right away. Cumulative tolerance signature represents signaturesthat by themselves may trigger too many false positive. Instead ofsimply abandoning these types of signatures, they can be bundled andanalyzed based on the frequency of occurrence in a pre-definedtimeframe, for example. This approach allows the firewall system 100 tostill leverage signatures that could occur naturally during the courseof normal application operation and be able to detect inappropriate useindicative of an attacker's methodology. A signature can refer to apattern or set of data in the network traffic data associate with aparticular web application 104.

Accordingly, firewall system 100 can include built-in security widgets.The security widgets can relate to inbound traffic flow. Examplesecurity widgets include behavioral analysis widgets and signaturedetection widgets. The following tables describe attributes for inboundtraffic flow including an abusive session, for a domain, and signature.

Behavioral Analysis Detection Abusive This control can identify anattack in progress by evaluating Session the volume of maliciousattempts sent by an IP during a time window The volume of attacks isdetermined through contributing security widgets IP in violation will bedeemed abusive and be blocked for a period of time

Custom Signature Detection This control can identify attacks embeddingunexpected domain in parameters of the HTTP request Many injection basedattacks will require leveraging a foreign domain for their attack to betruly beneficial. The domain is typically used for either additionalpayload or exfiltration of data All name/value pairs (Query string orwithin the request body) as well as HTTP headers are inspected Thewidget is supported by two configuration lists to assist in theclassification of discovered domain. The first one is a whitelist toensure valid domain can be excluded from detection The second one is alist of domains leveraged by known commercial/ open source tools tobetter the confidence level of vulnerability detection The configurationlist allows for the segregation between malicious and operational domainThe strategy is new and focuses on going after essential elements of anattack instead of pure syntax matching Request in violation will beblocked in accordance to the enforcement and network block switches

Standard Attack Signature Detection Signature The intent of this controlblueprint is to handle standard (Generic) signature violation of a givenattack type in accordance to the established signature grouping Zerotolerance signature will be immediately blocked in accordance to theenforcement and network block switches Cumulative tolerance signatureare by default allowed through until the volume received from an IP,during a given period of time exceeds a threshold Once exceeded,cumulative tolerance signature of a given attack type will be treated aszero tolerance for a pre- determined period of time

The security widgets can relate to outbound traffic flow. The followingtables describe attributes for outbound traffic flow:

Custom Signature Detection 404 The intent of this control is identifyinga discovery exercise in progress by evaluating the volume of HTTPresponse code 404 generated by the application during a time windowRequest in violation will be handled in accordance to the enforcementand network block switches for a period of time. In normal block mode,the response will be handled by the security stack instead of thetargeted application This control contributes to the overall volume ofattack monitored by the abusive session control

Standard Attack Signature Detection Signature The intent of this controlblueprint is to handle standard (Generic) signature violation of a givenattack type in accordance to the established signature grouping. Due tounderlying product limitation, all standard signature applied to theHTTP response are set as cumulative. Zero tolerance behavior can besimulated by setting the threshold to exceed at 0 Cumulative tolerancesignature are by default allowed through until the volume received froman IP, during a given period of time exceeds a threshold Once exceeded,cumulative tolerance signature of a given attack type will be treated aszero tolerance for a pre- determined period of time

Virtual Patch Protection The intent of this control blueprint is toremove any HTTP headers from the HTTP Response matching a pre-definedlist. This sanitization control is mainly used to remove informationleakage revealing application implementation e.g. Web serverversion/patch level; Development platform/tools version/patch levelSoftware version/patch level are used by attackers to easily discoverunpatched system and associated vulnerabilities Cookies The intent ofthis control is to automatically add missing security attributes onsensitive cookie to protect it against hijacking HTTP Only - Provides adirective to the browser not to make the cookie available to client-sideJavascript Secure - Provides a directive to the server not to transmitthe cookie over a non-SSL channel CORS The intent of this control is toprevent by default an application to allow all domain to make AJAXrequest to its resources. Cross origin resource sharing should bewhitelisted if multiple domain are required The control will remove anyinstances of the HTTP header “Access-Control-Allow-Origin” set to “*”Click- The intent of this control is to automatically add any missingjacking HTTP headers/security attributes required to protect theapplication resources against clickjacking across all major browsersCache The intent of this control is to automatically add missing HTTPControl headers/security attributes to ensure sensitive content is notcached locally by the browser

In some embodiments, each widget can have setting or switches associatedwith it. Each widget is configured for particular settings or switchesfor a particular web application 104. An example is a kill switch toapply or ignore the widget. The following table provides differentexample switches for widgets including kill switches, enforcementswitches and network block switches.

Switch Values Flow Control Kill 1 Indicates that the security widgetshould be ignored 0 Indicates that the security widget should be appliedEnforce- 1 Indicates that security widget should block an attack ment orpatch a detected vulnerability depending on the function performed 0Indicates that the HTTP Request should not be blocked nor should theHTTP Response be blocked or patched Network 1 Indicates that thesecurity widget should reply with Block a TCP reset or packet drop whenan attack is detected The implementation will be dependent on theposition of the WAF within the infrastructure. Packet drop should beimplemented where possible. Both TCP Reset or packet drop willnegatively impact automated vulnerability scanner causing them to eitherdecrease in performance by waiting for the dropped packets orinterpreting the TCP reset as communication problem with theapplication. Packet drop is the most impactful methodology to decreasethe ROI of the attacker. 0 Indicates that the security widget shouldreply with a typical rejection message when an attack is detected

In some embodiments, a security widget may have one or more thresholdsassociated with it. The thresholds can include volume thresholds, timethresholds, and so on. The following table list example configurationitems to control the frequency and time window attributes of securitywidgets

WAF Time Window Deployment Widget Volume (seconds) Penalty Hot/HotAbusive Abusive-Volume-HH Abusive- Abusive-Jail- Session Maximum numberof TimeWindow-HH TimeWindow-HH malicious HTTP Time window used to Timewindow an requests to be evaluate frequency offending IP is exceeded ofmalicious HTTP blacklisted for requests Command COMEXEC-Volume- COMEXEC-NA Execution Cumulative-HH TimeWindow-HH Maximum number of Time windowused to malicious HTTP evaluate frequency requests to be of maliciousHTTP exceeded requests SQLi SQLI- SQLI- NA VolumeCumulative-HHTimeWindow-HH Maximum number of Time window used to malicious HTTPevaluate frequency requests to be of malicious HTTP exceeded requestsXSS XSS- XSS- NA VolumeCumulative-HH TimeWindow-HH Maximum number ofTime window used to malicious HTTP evaluate frequency requests to be ofmalicious HTTP exceeded requests LDAP LDAP- LDAP- NA VolumeCumulative-HHTimeWindow-HH Maximum number of Time window used to malicious HTTPevaluate frequency requests to be of malicious HTTP exceeded requestsXPATH XPATH- XPATH- NA VolumeCumulative-HH TimeWindow-HH Maximum numberof Time window used to malicious HTTP evaluate frequency requests to beof malicious HTTP exceeded requests 404 404- 404- NA VolumeCumulative-HHTimeWindow-HH Maximum number of Time window used to discovery HTTPevaluate frequency requests to be of discovery HTTP exceeded requestsDirectory DIRECTORY- DIRECTORY- NA Indexing VolumeCumulative-HHTimeWindow-HH Maximum number of Time window used to malicious HTTPevaluate frequency requests to be of malicious HTTP exceeded requestsHot/ Abusive Abusive-Volume-HS Abusive- Abusive-Jail- Standby SessionMaximum number of TimeWindow-HS TimeWindow-HS malicious HTTP Time windowused to Time window an requests to be evaluate frequency offending IP isexceeded of malicious HTTP blacklisted for requests CommandCOMEXEC-Volume- COMEXEC- NA Execution Cumulative-HS TimeWindow-HSMaximum number of Time window used to malicious HTTP evaluate frequencyrequests to be of malicious HTTP exceeded requests SQLi SQLI- SQLI- NAVolumeCumulative-HS TimeWindow-HS Maximum number of Time window used tomalicious HTTP evaluate frequency requests to be of malicious HTTPexceeded requests XSS XSS- XSS- NA VolumeCumulative-HS TimeWindow-HSMaximum number of Time window used to malicious HTTP evaluate frequencyrequests to be of malicious HTTP exceeded requests LDAP LDAP- LDAP- NAVolumeCumulative-HS TimeWindow-HS Maximum number of Time window used tomalicious HTTP evaluate frequency requests to be of malicious HTTPexceeded requests XPATH XPATH- XPATH- NA VolumeCumulative-HSTimeWindow-HS Maximum number of Time window used to malicious HTTPevaluate frequency requests to be of malicious HTTP exceeded requests404 404- 404- NA VolumeCumulative -HS TimeWindow-HS Maximum number ofTime window used to discovery HTTP evaluate frequency requests to be ofmalicious HTTP exceeded requests Directory DIRECTORY- DIRECTORY- NAIndexing VolumeCumulative-HS TimeWindow-HS Maximum number of Time windowused to malicious HTTP evaluate frequency requests to be of maliciousHTTP exceeded requests

In some embodiments, a widget may have a virtual patch associated withit for compliance reporting. The compliance reporting may be stored in aresults file to provide an event log or example. The following tablelist example configuration items to control the frequency of applicationcompliance reporting

WAF Deploy- Virtual ment Patches Time Window (seconds) Hot/ AppliedComplianceReporting-TimeWindow-HH Hot Time window used to determine thefrequency of reporting vulnerability patching for one applicationExempted ComplianceExceptionReporting-TimeWindow- HH Time window used todetermine the frequency of reporting vulnerable application exemptedfrom the protection Hot/ Applied ComplianceReporting-TimeWindow-HSStandby Time window used to determine the frequency of reportingvulnerability patching for one application ExemptedComplianceExceptionReporting-TimeWindow- HS Time window used todetermine the frequency of reporting vulnerable application exemptedfrom the protection

In some embodiments, widgets may have lists associated there with. Anexample list relates to Hot-Hot WAF Deployment security widget. Theframework can involve the creation of a list of application deployed ina hot-hot configuration. The API 214 can provide for the systematic andappropriate selection of configuration for the widgets. In some exampleconfigurations, a list can depict the VIP sitting in front of theapplication that also exists in a separate WAF instance.

Another example list relates to Foreign Domain security widget. Theforeign domain security widget can involve the creation of two lists tobetter filter detected domains and produce both meaningful enforcementand notification.

Type List Whitelist TrustedDomains List of valid domains that can beexpected to be embedded in the HTTP request QueryString name/value pairsBody name/value pairs HTTP Headers Known TestingToolDomains Tools Listof invalid domains that can be expected to be embedded in the HTTPrequest QueryString name/value pairs Body name/value pairs HTTP HeadersThese domains are commonly leveraged by known security tools and cannotbe actioned upon e.g. RSA shutdown

In some embodiments, security widgets implement an exception list. Theexception list allows for the identification of application orapplication component that should be exempted from the security widget.The table below provide a breakdown of the lists that can support thebuilt-in security widgets

Implementation ExceptionAbusiveSession ExceptionEmbeddedDomainExceptionSQLi ExceptionXSS ExceptionLDAP ExceptionXPath Exception404ExceptionDirectoryBrowsing RemovableHeaders ExceptionCookiesExceptionCORS ExceptionClickJacking ExceptionCacheControl

In some embodiments, firewall system 100 provides a development API 214to generate and configure widgets. The API 214 provides an abstractionlayer to the underlying security product and is designed to facilitatefuture updates. For example the API 214 can be developed with iRules andmake use of TCL language. FIGS. 7, 8, and 9 provide hierarchicaldiagrams that describe the API virtual objects and associated methods.

FIG. 7 is an example API 214 hierarchical diagram 700 for maliciousrequest handling according to some embodiments. The API 214 includesvirtual objects and methods for malicious request handling. The API 214defines virtual objects including an abusive session object 702, asignature object 704, HTTPS object 706, URL object 708, enforcementswitch object 710, ASM bridge object 712, and 404 object 714. Eachvirtual object includes one or more associated methods. For example, theabusive session object 702 can include an increment method, get accountmethod, is abusive method, block IP method, is IP blacklisted method,and so on. As another example, the signature object 704 can include aprocess HTTP request method, process HTTP response method, processembedded URL method, and so on. As another example, the HTTPS object 706can include an acquire POST method. The URL object 708 can include adetect invalid domain method. The enforcement switch object 710 caninclude a process for ASM request method, process for ASM responsemethod, process for non-ASM request method, process for non-ASM responsemethod, and so on. The ASM bridge object 712 can include a requestunblocking method, a maintain block and method, is unblocking requestedmethod, unblock request method, and so on. The 404 object 714 caninclude an increment method, is threshold exceeded method, and so on.

FIG. 8 is an example API 214 hierarchical diagram 800 for applicationvulnerability patching according to some embodiments. The API 214includes virtual objects and methods for application vulnerabilitypatching. The API 214 defines virtual objects including HDP headersobjects 802 and cookies objects 804. The HDP headers objects 802 caninclude a remove any method, remove if value match method, when match apen value if method, insert pair if method, set default empty method,replace value not in method, and so on. The cookies objects 804 caninclude a set secure method, set HTTPOnly method, and so on.

FIG. 9 is an example API 214 hierarchical diagram 900 for frameworksupport according to some embodiments. The API 214 includes virtualobjects and methods for framework support. The API 214 includes virtualobjects such as state objects 902, configuration objects 904, logobjects 906, stack trace objects 908, and monitoring table objects 910.The state objects 902 can include is kill switch enabled method, is killswitch disabled method, is exception disabled method, is exceptionenabled method, is cookie exception disabled method, is cookie exceptionenabled method, is hot hot method, is value in method, and so on. Theconfiguration objects 904 can include a get threshold method, a getvolume method, a get cumulative volume threshold, time window threshold,and so on. The log objects 906 can include abusive session method,abusive session exception method, embedded URL method, signature bymethod, high-frequency method, high-frequency exception method, virtualfor noncompliance method, virtual method, and so on. The stack traceobjects 908 can include a reset method, add method, print method, and soon. The monitoring table objects 910 can include an increment method,get current a method, verify lifetime change method, and so on.

As noted, the API 214 includes virtual objects and methods for maliciousrequest handling or abusive session objects 702. The Abusive Sessionobject 702 is responsible for tracking malicious activity in apre-determined time window for a given IP and determining when an IPshould be blocked.

Object Functions Description Abusive Increment Increments the count ofmalicious request Session received for a given IP GetCount Returns thecurrent count of malicious request received for a given IP IsAbusiveReturns a Boolean value indicating whether the count of maliciousrequest received for a given IP in the pre-determined time window hasexceeded a threshold BlockIP Sets a flag to indicate that traffic from agiven IP should be blocked IsIPBlacklisted Returns a Boolean valueindicating whether a given IP is blocked or not

As noted, the API 214 includes virtual objects and methods for signatureobjects 704. The Signature object is responsible for handling theoutcome of detecting a signature based violation the following examples:Standard signature—HTTP Request; Standard signature—HTTP Response; andCustom signature—HTTP Request.

Object Functions Description Signature ProcessHTTPRequest Genericfunction to process HTTP Request based signature detection. The functionencompasses all the required logic to handle: Security widget switches;Integration with the abusive session security widget; Cumulative andMandatory Signature set requirements; Framework logging requirements.ProcessHTTPResponse Generic function to process HTTP Response basedsignature detection. The function encompasses all the required logic tohandle: Security widget switches; Integration with the abusive sessionsecurity widget; Cumulative signature set requirements; Frameworklogging requirements. ProcessEmbeddedURL Processes foreign domaindetection in HTTP request parameters. The function encompasses all therequired logic to handle: Security widget switches; Integration with theabusive session security widget; Framework logging requirements.

As noted, the API 214 includes virtual objects and methods for HTTPobjects 706. The HTTP object is responsible for handling complex and/oruntypical HTTP manipulation.

Object Functions Description HTTP AcquirePOSTPayload Handles thecollection of the HTTP Post body content

As noted, the API 214 includes virtual objects and methods for URLobjects 708. The URL object is responsible for handling URL basedviolation detection.

Object Functions Description URL DetectInvalidDomain Returns the firstnon-whitelisted domain found in the supplied string

As noted, the API 214 includes virtual objects and methods forenforcement switch objects 710. The Enforcement Switch object isresponsible for handling both enforcement and network block switchesaccording to the underlying detection regulation (product based orcustom).

Object Functions Description Enforce- ProcessForASMRequest Processes thesecurity widget ment enforcement and network Switch block switches foran HTTP Request based detection regulated through the F5 ASMProcessForASMResponse Processes the security widget enforcement andnetwork block switches for an HTTP Response based detection regulatedthrough the F5 ASM ProcessForNonASMRequest Processes the security widgetenforcement and network block switches for an HTTP Request baseddetection manually regulated ProcessForNonASMResponse Processes thesecurity widget enforcement and network block switches for an HTTPResponse based detection manually regulated

As noted, the API 214 includes virtual objects and methods for ASMbridge objects 712. The ASM Bridge object is responsible for controllingthe underlying security product in regard to blocking/unblocking arequest.

Object Functions Description ASM RequestUnblocking Maintains a flag tokeep track of Bridge unblocking request sent by security widgets e.g.When the kill switch is enabled When the application or applicationcomponent is exempted MaintainBlocking Sets a flag to indicate that theHTTP request should be blocked regardless of other security widget'sflag setting IsUnblockingRequested Returns a Boolean value indicatingwhether there has been a request to unblock the HTTP requestUnblockRequest Removes the block on an HTTP request

As noted, the API 214 includes virtual objects and methods for 404objects 714. The 404 object is responsible for tracking discoveryactivity associated to resource name guessing.

Object Functions Description 404 Increment Increments the number ofdiscovery request received for a given IP IsThresholdExceeded Returns aBoolean value indicating whether the number of discovery requestreceived for a given IP in the pre-determined time window has exceeded athreshold

Embodiments described herein provide an API 214 was functions forApplication Vulnerability Patching such as the examples shown in FIG. 8.The functions for application vulnerability patching can implement thelogic to handle the enforcement and network block switches. The HTTPHeaders object 802 is responsible for providing simple and direct meansto validate and/or update HTTP headers and their various implementatione.g. Single value; Embedded name/value pairs; and Delimited multiplevalues.

Object Functions Description HTTP RemoveAnyMatchingDataGroup Genericfunction to remove Headers any headers in the HTTP Response matching apre- defined list. RemoveIfValueMatch Generic function to remove aheader in the HTTP Response if the value is a match.WhenMatchAppendValueIfMissing Generic function to perform headerpatching: Detection Determine if the header of interest contains a givenvalue If true, determine if a second given value is missing PatchingAppend a second given value to a header using the supplied delimiterInsertPairNameIfMissing Generic function to perform header patching:Detection Determine if the header of interest contains a given pair namePatching Append the name/value pair if pair name is missingSetDefaultValueIfEmpty Generic function to perform header patching:Detection Determine if the header of interest is empty or does not existPatching Set the header with a given value if missingReplaceValueIfNotInList Generic function to perform header patching:Detection Determine if the header of interest contains a given valueavailable in a pre-determined list Patching Replace value with a secondgiven value if not in the list

The Cookie object 804 is responsible for streamlining the process ofmaintaining security based cookie attributes.

Object Functions Description Cookie SetSecure Adds the “Secure”attribute to a cookie if the traffic is over SSL and attribute ismissing. SetHTTPOnly Adds the “HTTPOnly” attribute to a cookie if theattribute is missing.

The API 214 provides framework support such as the example shown in FIG.9. The State object 902 is responsible for providing streamlined accessto switches and exception list affecting the framework workflow.

Object Functions Description State IsKillSwitchEnabled Returns a Booleanvalue indicating if a security widget kill switch is enabledIsKillSwitchDisabled Returns a Boolean value indicating if a securitywidget kill switch is disabled IsVIPExceptionDisabled Returns a Booleanvalue indicating if an application exemption is disabledIsVIPExceptionEnabled Returns a Boolean value indicating if anapplication exemption is enabled IsVIPCookieExceptionDisabled Returns aBoolean value indicating if an application component exemption isdisabled IsVIPCookieExceptionEnabled Returns a Boolean value indicatingif an application component exemption is enabled IsVIPHotHot Returns aBoolean value indicating if an application is deployed with a Hot-HotWAF IsValueInDataGroup Returns a Boolean value indicating if a valueexist in a given DataGroup

The Config object 904 is responsible for providing streamlined access tothe configurable thresholds affecting the framework workflow.

Object Functions Description Config GetThreshold Generic function thatreturns the value set for a given threshold and the application WAFdeployment GetVolumeThreshold Returns the value set for a given volumethreshold GetCumulativeVolumeThreshold Returns the value set for a givencumulative volume threshold TimeWindowThreshold Returns the value setfor a given time window threshold

The Log object 906 is responsible for providing streamlined access tothe underlying security product logging functionality.

Object Functions Description Log AbusiveSession Standardized andcentralized logging for an Abusive Session violationAbusiveSessionException Standardized and centralized logging for anAbusive Session violation exception EmbeddedURL Standardized andcentralized logging for an foreign domain embedded URL violationSignatureViolation Standardized and centralized logging for standardsignature based violation High Frequency404 Standardized and centralizedlogging for high frequency of HTTP response 404HighFrequency404Exception Standardized and centralized logging for highfrequency of HTTP response 404 exception VirtualPatchingForNonComplianceStandardized and centralized logging for application virtual patchingVirtualPatchingForException Standardized and centralized logging forapplication virtual patching exception

The Stack Trace object 908 is responsible for providing a customizablereporting on workflow and the various security events firing.

Object Functions Description Stack Reset Reset stack trace for an IPTrace Add Add entry in the stack trace for an IP Print Log stack tracefor an IP

The Monitor Table object 910 is responsible for monitoring andmaintaining a variety of key security attributes that support thesecurity widgets

Object Functions Description Monitoring Increment Generic function totrack the Table number of instances for a given security attributeGetCurrentValue Returns the current count for a given security attributeVerifyLifetimeChange Validates if the configured lifetime of the dataelement being monitored has changed. In the event of a change, the clockis reset

FIG. 10 is a diagram of a security stack process 1000 according to someembodiments. At 1002, the security stack receives an HTTP request fromthe web application. At 1004, the security stack initializes statehandling in response to the request. At 1006, the security stackimplements detection abusing calls. At 1008, 1010, the security stackimplements detection foreign domain processing for the HTTP request andthe request data. At 1012, the security stack implements detectionembedded domain processing for the ASM request. At 1014, the securitystack implements detection signature processing for COM EXEC signaturesof the ASM request. At 1016, the security stack implements detectionsignature processing for SQL signatures of the ASM request. At 1018, thesecurity stack implements detection signature processing for XSSsignatures of the ASM request. At 1020, the security stack implementsdetection signature processing for LDAP signatures of the ASM request.At 1022, the security stack implements detection signature processingfor XPATH signatures of the ASM request. At 1024, the security stackimplements post inbound state handling. At 1026, the security stackreceives an HTTP response. At 1028, the security stack implementsdetection excessive 404 processing for the HTTP response. At 1030, thesecurity stack implements detection directory indexing. At 1032, thesecurity stack implements post outbound state handling. At 1034, 1036,1038, 1040, 1042, the security stack implements virtual patch processingincluding info headers, cookies, open CORS, clickjacking, cache control,and so on. At 1044, the security stack finalizes state handling.

FIG. 11 is a diagram of a security stack process 1100 for abusivesession detection according to some embodiments. The process 1100 startsat 1102 from a previous process for the firewall. At 1104, the abusivesession involves a determination of whether a kill switch is enabled. Ifnot, at 1108, the session determines whether this frequency is above apredetermined threshold. If so, at 1110, the process logic codedetermines whether an exception is enabled. If the exception is enabled,at 1112, the process logic code implements exception system logging. Ifthe exception is not enabled, at 1114, the process implements violationsystem logging. At 1116, the process determines whether enforcement isenabled. If so, at 1118, the process logic code determines whether thenetwork lock is enabled. If so, 1122, the process logic code implementsa TCP reset. If not, at 1120, the process implements an API basedrejected response. If the kill switch is enabled (1104) or the frequencyis below the threshold (1108), at 1106, the process 1100 moves to thenext process for the firewall.

FIGS. 12A and 12B are diagrams of a security stack process 1200 forembedded domain detection according to some embodiments. The process1200 starts at 1202 from a previous process for the firewall. At 1204,the process logic code determines whether the kill switch is enabled. Ifnot, at 1208, the process logic code identifies a URL and, at 1210,determines whether it is an embedded domain. If so, at 1212, the processlogic code determines whether it is an exception. If it is an exception,at 1214, the process logic code determines if the firewall system islogging. If so, at 1216, the process logic code implements exceptionsystem logging. At 1218, the process logic code raises an exceptionnotification event. If it is not an exception, at 1220, the processlogic code implements an increment attack count for IP blacklisting. At1222, the process logic code determines whether it is a testing tool. At1224, the process logic code determines if the firewall system islogging. At 1226, the process logic code implements testing tool systemlogging. At 1228, the process logic code raises a testing tool blockingevent. At 1230, the process logic code determines if enforcement isenabled. At 1232, the process logic code sets an unblock request flag.If enforcement is enabled, at 1234, the process logic code determines ifthe network block is enabled. At 1236, the process logic code implementsa TCP reset. At 1238, the process logic code implements an event basedrejected URL response. If the process logic code determines that it isnot a testing tool, at 1244, the process logic code determines if thefirewall system is logging. At 1242, the process logic code implementsunexpected domain system logging. At 1240, the process logic code raisesan unexpected domain blocking event. At 1206, the process 1200 moves tothe next process for the firewall.

FIGS. 13A and 13B are diagrams of a security stack process 1300 forstandard signature detection according to some embodiments. The process1300 starts at 1302 from a previous process for the firewall. At 1304,the process logic code determines whether the kill switch is enabled. Ifthe kill switch is enabled, at 1306, the process logic code sets theunblock request flag. If not, at 1310, the process logic code determineswhether there is an attack type match. At 1312, the process logic codedetermines whether there is an exception. If so, at 1314, the processlogic code determines whether the firewall system is logging. At 1316,the process logic code implements exception system logging (once pertime window). At 1318, the process logic code raises an exceptionnotification event. At 1320, the process logic code sets an unblockrequest flag.

If it is not an exception, at 1322, the process logic code increments anattack count IP blacklisting. At 1324, the process logic code determineswhether there is a cumulative tolerance signature. If there is acumulative tolerance signature, at 1326, the process logic codedetermines whether the frequency is over a threshold. If so, at 1328,the process logic code raises the cumulative tolerance blocking event.At 1330, the process logic code determines whether the firewall systemis logging. If so, at 1332, the process logic code implements cumulativetolerance system logging (once per time window). At 1334, the processlogic code determines whether enforcement is enabled. If not, at 1336,the process logic code sets an unblock request flag. If so, at 1338, theprocess logic code determines if the network block is enabled. At 1340,the process logic code implements a TCP reset. At 1342, the processlogic code implements an event based rejected URL response.

If there is not a cumulative tolerance signature, at 1346, the processlogic code determines whether the firewall system is logging. If so, at1344, the process logic code implements a zero tolerance system loggingand proceeds to determine whether enforcement is enabled at 1334. At1308, the process 1300 moves to the next process for the firewall.

FIG. 14 is a diagram of a security stack process 1400 for response codedetection according to some embodiments. The process 1400 starts at 1402from a previous process for the firewall. At 1404, the process logiccode determines whether the kill switch is enabled. If not, at 1408, theprocess logic code determines whether there is a 404 error message (HTTPresponse code). If so, at 1410, the process logic code determineswhether there is an exception. If there is an exception, at 1412, theprocess logic code implements exception system logging. If there is notan exception, at 1414, the process increments attack count IPblacklisting. At 1416, the process logic code determines if thefrequency is greater than a threshold. If so, the process logic codeimplements violation system logging. At 1420, the process logic codedetermines if enforcement is enabled. At 1422, the process logic codedetermines whether the network block is enabled. At 1426, the processlogic code implements a TCP reset. At 1424, the process logic codeimplements an API based rejected URL response. At 1406, the process 1400moves to the next process for the firewall.

FIG. 15 is a diagram of a security stack process 1500 for standardsignature detection according to some embodiments. The process 1500starts at 1502 from a previous process for the firewall. At 1504, theprocess logic code determines whether there is a kill switch enabled. Ifnot, at 1508, the process logic code determines whether there is anattack type match. If so, at 1510, the process logic code determineswhether there is an exception. If there is an exception, at 1512, theprocess logic code determines whether the firewall system is logging. At1514, the process logic code implements exception system logging. Ifthere is not an exception, at 1516, the process logic code incrementsattack count IP blacklisting. At 1518, the process logic code determineswhether the frequency is greater than a threshold. If so, at 1520, theprocess logic code determines whether the firewall system is logging. At1522, the process logic code implements cumulative tolerance systemlogging. At 1524, the process logic code determines if enforcement isenabled. At 1526, the process logic code determines if the network blockis enabled. If the network block is enabled, at 1528, the process logiccode implements a TCP reset. If the network block is not enabled, at1530, the process logic code implements an API based rejected URLresponse. At 1506, the process 1500 moves to the next process for thefirewall.

FIG. 16 is a diagram of a security stack process 1600 for post inboundrequest handling according to some embodiments. The process 1600 startsat 1602 from a previous process for the firewall. At 1604, the processlogic code determines whether a un-block is requested. If so, at 1608,the process logic code unblocks the request. At 1606, the process 1600moves to the next process for the firewall.

FIG. 17 is a diagram of a security stack process 1700 for HTTP headersaccording to some embodiments. The process 1700 starts at 1702 from aprevious process for the firewall. At 1704, the process logic codedetermines whether there is a kill switch enabled. If not, at 1708, theprocess logic code determines whether there is an exception. If there isan exception, at 1710, the process logic code implements complianceexception system logging. If there is not an exception, at 1712, theprocess logic code determines whether there are HTTP headers. If not, at1714, the process logic code determines whether there is a complianceviolation. If so, at 1718, the process logic code implements virtualpatch system logging. If there are HTTP headers, at 1716, the processlogic code determines whether the HTTP headers are blacklisted. If so,at 1720, the process logic code determines whether enforcement isenabled. If so, then at 1722, the process logic code removes the HTTPheader. At 1706, the process 1700 moves to the next process for thefirewall.

FIGS. 18A and 18B are diagrams of a security stack process 1800 forcookies according to some embodiments. The process 1800 starts at 1802from a previous process for the firewall. At 1804, the process logiccode determines whether a kill switch is enabled. If not, at 1808, theprocess logic code determines whether there are cookies. If there arecookies, at 1810, the process logic code determines whether there is anexception. If there is an exception, at 1812, the process logic codeimplements compliance exception system logging. If there is not anexception, at 1814, the process logic code determines whether there isSSL. If there is SSL, at 1816, the process logic code determines whetherthere is a secure flag. If there is a secure flag, at 1824, the processlogic code implements a junction. At 1826, the process logic codedetermines whether there is HTTP only. If so, the process logic codeimplements a junction at 1834 and returns to 1808. If there is not asecure flag, at 1818, the process logic code determines whether there isenforcement blocking. If so, at 1820, the process logic code implementsa patch cookie attribute. At 1822, the process logic code implementscompliance virtual patch system logging. If there is not only HTTP, at1828, the process logic code determines whether enforcement is enabled.If so, at 1830, the process logic code implements patch cookieattribute. At 1832, the process logic code implements compliance virtualsystem logging. At 1806, the process 1800 moves to the next process forthe firewall.

FIG. 19 is a diagram of a security stack process 1900 for CORS accordingto some embodiments. The process 1900 starts at 1902 from a previousprocess for the firewall. At 1904, the process logic code determineswhether there is a kill switch enabled. If not, at 1908, the processlogic code determines whether there is an exception. If there is anexception, at 1910, the process logic code implements complianceexception system logging. If there is not an exception, at 1912, theprocess logic code determines whether there is an HTTP header valuematch. If so, at 1914, the process logic code determines whetherenforcement is enabled. If so, at 1916, the process logic code removesthe HTTP header. If not, at 1918, the process logic code implementscompliance virtual patch system logging. At 1906, the process 1900 movesto the next process for the firewall.

FIG. 20 is a diagram of a security stack process 2000 for clickjackingaccording to some embodiments. The process 2000 starts at 2002 from aprevious process for the firewall. At 2004, the process logic codedetermines whether there is a kill switch enabled. If not, at 2010, theprocess logic code determines whether there is an exception. If there isan exception, at 2008, the process logic code implements complianceexception system logging. If there is not an exception, at 2012, theprocess logic code determines whether there is a valid CSP header. Ifnot, at 2014, the process logic code determines whether there isenforcement blocking and if so, at 2016, implements a patch header. Ifthe CSP header is valid, at 2020, the process logic code determineswhether frame options (e.g. X-frame options) are valid. If not, at 2022,the process logic code determines whether enforcement is enabled. If so,at 2024, the process logic code implements a patch header. At 2026, theprocess logic code implements compliance virtual patch system logging.At 2006, the process 2000 moves to the next process for the firewall.

FIG. 21 is a diagram of a security stack process 2100 for cache controlaccording to some embodiments. The process 2100 starts at 2102 from aprevious process for the firewall. At 2104, the process logic codedetermines whether there is a kill switch enabled. If not, at 2108, theprocess logic code determines whether there is an exception. If there isan exception, at 2110, the process logic code implements complianceexception system logging. If there is not an exception, at 2112, theprocess logic code determines whether there is an HTTP header valuematch. If so, at 2114, the process logic code determines whetherenforcement is enabled. If so, at 2116, the process logic codeimplements a patch header. If not, at 2118, the process logic codeimplements compliance virtual patch system logging.

The firewall system 100 connects to other components in various waysincluding directly coupled and indirectly coupled via the network 108.Network 108 (or multiple networks) is capable of carrying data. Network108 can involve wired connections, wireless connections, or acombination thereof. Network 108 may involve different networkcommunication technologies, standards and protocols.

Program code is applied to input data to perform the functions describedherein and to generate output information. The output information isapplied to one or more output devices. In some embodiments, thecommunication interface may be a network communication interface. Inembodiments in which elements may be combined, the communicationinterface may be a software communication interface, such as those forinter-process communication. In still other embodiments, there may be acombination of communication interfaces implemented as hardware,software, and combination thereof.

Throughout the foregoing discussion, numerous references will be maderegarding servers, services, interfaces, portals, platforms, or othersystems formed from computing devices. It should be appreciated that theuse of such terms is deemed to represent one or more computing deviceshaving at least one processor configured to execute softwareinstructions stored on a computer readable tangible, non-transitorymedium. For example, a server can include one or more computersoperating as a web server, database server, or other type of computerserver in a manner to fulfill described roles, responsibilities, orfunctions.

Various example embodiments are described herein. Although eachembodiment represents a single combination of inventive elements, allpossible combinations of the disclosed elements include the inventivesubject matter. Thus if one embodiment comprises elements A, B, and C,and a second embodiment comprises elements B and D, then the inventivesubject matter is also considered to include other remainingcombinations of A, B, C, or D, even if not explicitly disclosed.

The term “connected” or “coupled to” may include both direct coupling(in which two elements that are coupled to each other contact eachother) and indirect coupling (in which at least one additional elementis located between the two elements).

The technical solution of embodiments may be in the form of a softwareproduct. The software product may be stored in a non-volatile ornon-transitory storage medium, which can be a compact disk read-onlymemory (CD-ROM), a USB flash disk, or a removable hard disk. Thesoftware product includes a number of instructions that enable acomputer device (personal computer, server, or network device) toexecute the methods provided by the embodiments.

The embodiments described herein are implemented by physical computerhardware, including computing devices, servers, receivers, transmitters,processors, memory, displays, and networks. The embodiments describedherein provide useful physical machines and particularly configuredcomputer hardware arrangements. The embodiments described herein aredirected to electronic machines and methods implemented by electronicmachines adapted for processing and transforming electromagnetic signalswhich represent various types of information. Computer or logic code canconfigure hardware elements, for example.

For simplicity only one firewall system 100 is shown but there may beadditional firewall systems 100 operable by user devices 102 to accessweb applications 104 and exchange data. The firewall system 100 has atleast one processor, a data storage device (including volatile memory ornon-volatile memory or other data storage elements or a combinationthereof), and at least one communication interface. The computing devicecomponents may be connected in various ways including directly coupled,indirectly coupled via a network, and distributed over a wide geographicarea and connected via a network (which may be referred to as “cloudcomputing”).

FIG. 22 is a diagram of a computing device for implementing aspects ofthe firewall system according to some embodiments. The embodiments ofthe devices, systems and methods described herein may be implemented ina combination of both hardware and software. These embodiments may beimplemented on programmable computers, each computer including at leastone processor, a data storage system (including volatile memory ornon-volatile memory or other data storage elements or a combinationthereof), and at least one communication interface.

Firewall system 100 includes at least one processor 2202, memory 2204,at least one I/O interface 2206, and at least one network interface2208.

Each processor 2202 may be, for example, any type of general-purposemicroprocessor or microcontroller, a digital signal processing (DSP)processor, an integrated circuit, a field programmable gate array(FPGA), a reconfigurable processor, or any combination thereof.

Memory 2204 may include a suitable combination of any type of computermemory that is located either internally or externally such as, forexample, random-access memory (RAM), read-only memory (ROM), compactdisc read-only memory (CDROM), electro-optical memory, magneto-opticalmemory, erasable programmable read-only memory (EPROM), andelectrically-erasable programmable read-only memory (EEPROM),Ferroelectric RAM (FRAM) or the like.

Each I/O interface 2206 enables firewall system 100 to interconnect withone or more input devices, such as a keyboard, mouse, camera, touchscreen and a microphone, or with one or more output devices such as adisplay screen and a speaker.

Each network interface 2208 enables firewall system 100 to communicatewith other components, to exchange data with other components, to accessand connect to network resources, to serve applications, and performother computing applications by connecting to a network (or multiplenetworks) capable of carrying data.

Firewall system 100 is operable to register and authenticate users(using a login, unique identifier, and password for example) prior toproviding access to applications, a local network, network resources,other networks and network security devices.

Although the embodiments have been described in detail, it should beunderstood that various changes, substitutions and alterations can bemade herein without departing from the scope as defined by the appendedclaims.

Moreover, the scope of the present application is not intended to belimited to the particular embodiments of the process, machine,manufacture, composition of matter, means, methods and steps describedin the specification. As one of ordinary skill in the art will readilyappreciate from the disclosure of the present invention, processes,machines, manufacture, compositions of matter, means, methods, or steps,presently existing or later to be developed, that perform substantiallythe same function or achieve substantially the same result as thecorresponding embodiments described herein may be utilized. Accordingly,the appended claims are intended to include within their scope suchprocesses, machines, manufacture, compositions of matter, means,methods, or steps.

As can be understood, the embodiments described above and illustratedare intended to be examples.

What is claimed is:
 1. A firewall system comprising a hardware processorexecuting code to configure widgets for web applications and a securitystack, the security stack implementing an order of execution for thewidgets and an activation configuration to toggle each widget to enableor disable security actions on a per web application basis, the widgetscomprising security widgets and state control widgets, the securitywidgets having code to implement behaviour analysis detection andsignature detection for a request received from a web application, andthe state control widgets having code to implement decision making fornetwork traffic.
 2. The firewall system of claim 1, wherein the statecontrol widgets comprise an initialization state control widget thatprovides a placeholder for security state logic to be executed as soonas the request is received and prior to any security detection by thesecurity widgets.
 3. The firewall system of claim 1, wherein the statecontrol widgets comprise a post-inbound state control widget thatprovides a placeholder for security state logic to be executed after therequest has been inspected for possible attack violation and before itis either sent to the web application or rejected all together.
 4. Thefirewall system of claim 1, wherein the state control widgets comprise apost-outbound state control widget provides a placeholder for securitystate logic to be executed after the response has been inspected forpossible attack violation and before virtual patching.
 5. The system ofclaim 1, wherein a widget is a code segment that implements webapplication firewall (WAF) event listeners to provide particularfirewall control functionality and interact with incoming or outgoingnetwork traffic from the web applications.
 6. The system of claim 1,wherein a widget that is disabled for a particular web application isbypassed by network traffic for the particular web application.
 7. Thesystem of claim 1, wherein the widgets includes a zero-tolerance widgetsuch that any triggering of the zero-tolerance widget results in thewidget performing a prescribed action.
 8. The system of claim 1, whereinthe widgets include a widget such that a prescribed action is only takenif a certain threshold of activity is surpassed over a given time. 9.The system of claim 1 wherein each widget has settings or switches, theswitches including a kill switch to apply or ignore the widget.
 10. Thesystem of claim 1 wherein a security widget comprises code to implementsecurity controls to process and inspect network traffic for a webapplication, the security controls for different types of detection in agiven portion of data exchange with a web application.
 11. The system ofclaim 1 wherein the security stack provides the order of execution forthe widgets by assigning an execution priority value to each widget todefine timing data for execution of the respective widget.
 12. Thesystem of claim 1, wherein the signature detection comprises customsignature detection and attack signature detection.
 13. The system ofclaim 1 wherein the security widgets comprises code to implement virtualpatch protection to remediate application security vulnerabilitiesthrough HyperText Transfer Protocol (HTTP) response modification. 14.The system of claim 1 wherein the behaviour analysis detection comprisescode to implement behavioral analysis type of detection to blacklistaddresses and perform pattern detection.
 15. The system of claim 1wherein the signature detection comprises code to implement customsignature type of detection to detect references to malicious domainsand complex multi-staged signatures.
 16. The system of claim 1 whereinthe signature detection comprises code to implement attack signaturetype of detection to track and determine frequency of signaturedetection for cumulative tolerance attack sets.
 17. The system of claim1 wherein a widget implements at least one web application firewall(WAF) event listener to enable the widget to interact with inbound andoutbound network traffic, wherein the WAF event listener declares apriority value for the security stack to determine the order ofexecution.
 18. The system of claim 1 wherein a security widgetimplements a set of switches to allow granular flow control, the set ofswitches comprising at least one of a kill switch, enforcement switchand a block switch, the kill switch providing the ability to disable asecurity control at a policy level, the enforcement switch providing theability to set a control in either detection or protection mode, theblock switch providing the ability to force the control to reset aTransmission Control Protocol (TCP) connection instead of sending back aviolation message through a HyperText Transfer Protocol (HTTP) response.19. The system of claim 1 wherein a widget is an attack signature set toenable different types of tolerance for a particular activity relatingto a web application, the different types of tolerance being zerotolerance and cumulative tolerance.
 20. The system of claim 1 whereinthe security widgets comprises a set of security widgets relating toinbound traffic flow and another set of security widgets relating tooutbound traffic flow, wherein the set of security widgets relating toinbound traffic flow comprise an abusive session control, a domaincontrol, and a signature control, wherein the set of security widgetsrelating to outbound traffic flow comprise a signature control andvirtual patch protection.
 21. The system of claim 1 wherein a securitywidget has one or more thresholds, the thresholds relating to volumethresholds or time thresholds.
 22. A process for firewall systemcomprising: at a processor, receiving a request from a web applicationto process network traffic; triggering an initialization state controlwidget; processing the network traffic using security widgets havingsecurity logic to implement behaviour analysis detection, customsignature detection for the request, and attack signature detectionbased on the request for attack signatures; triggering a post-inboundstate control widget; processing the network traffic using a set ofsecurity widgets having security logic to implement custom signaturedetection for a response, and standard attack signature detection forthe response; triggering a post-outbound state control widget;implementing viral patch protection; and triggering a finalization statecontrol widget.
 23. The process of claim 22, wherein the initializationstate control widget provides a placeholder for security state logic tobe executed as soon as the request is received and prior to any securitydetection by the security widgets.
 24. The process of claim 22, whereinthe post-inbound state control widget provides a placeholder forsecurity state logic to be executed after the request has been inspectedfor possible attack violation and before it is either sent to the webapplication or rejected all together.
 25. The process of claim 22,wherein the post-outbound state control widget provides a placeholderfor security state logic to be executed after the response has beeninspected for possible attack violation and before virtual patching.